\documentclass{article}

%\usepackage[latin1]{inputenc}

% \usepackage[latin1]{inputenc}
% \usepackage[brazil]{babel}
%\usepackage[T1]{fontenc}		% fontes PS com acentos
\usepackage[brazil]{babel}	
\usepackage[utf8]{inputenc}
% \usepackage{amsmath}
% \usepackage{amsfonts}
% \usepackage{amssymb}

\title{Respostas}
\author{Plácido A. Souza Neto}
%\date{\today} 
 

 
% \def\ie{\textit{i.e.}} 
% \def\eg{\textit{e.g. }}
% \def\wrt{\textit{wrt }}
% \def\A{\hbox{${\cal A}$}}    
% \def\C{\hbox{${\cal C}$}}
% \def\O{\hbox{${\cal O}$}}
% \def\D{\hbox{${\cal D}$}}
% \def\F{\hbox{${\cal F}$}}

\begin{document}
 
\maketitle

\section{Questionamentos e Sugest\~oes do Prof. Nelson Souto Rosa}
\label{sec:questions}

\begin{quotation}\sf\footnotesize
\noindent
1 - Qual a no\c c\~ao de ``confiabilidade'' usada no trabalho? Apesar de constar
no t\'itulo (``A methodology for building reliable service-based applications'') e
em v\'arias partes do documento, a metodologia proposta e os meta-modelos n\~ao
apresentam nenhuma caracter\'istica que sugira o desenvolvimento de aplica\c
c\~oes deste tipo. Na pr\'atica, a proposta da tese aparenta ter sido concebida
para o desenvolvimento de aplica\c c\~oes orientadas a servi\c cos em geral.      
\end{quotation}

% ``Reliability is even more important  in  object-oriented  programming than 
% elsewhere. Meyer presents in \cite{Meyer92,MeyerN93} how to reduce bugs by
% building software components on the basis of carefully designed contracts.''
% 
% Thus, based on this concept, a software component, whether a service or not,
% which is designed based on contracts has reduced the amount of bugs, becoming
% more reliable. In the specific case of services, which are loosely coupled
% components, the specification and verification of these contracts must be
% performed by the services' orchestrator, who shall verify the validity and
% execution of these contracts.
% 
% The concept of \textit{reliability} used in the thesis, is the concept presented
% by \textit{Bertrand Meyer} \cite{Meyer92,MeyerN93,Meyer97} in his definition of
% \textbf{Design by Contract}.
% 
% Bertrand Meyer \cite{Meyer97} gives these definitions, about
% \textit{Correctness, Robustness} and \textit{Reliability} :
% 
% . \textit{Correctness}: The ability of software products to perform their exact
% tasks, as defined by their specification.
% 
% . \textit{Robustness}: The ability of software systems to react appropriately to
% abnormal conditions.
% 
% . \textit{Reliability}: A concern encompassing correctness and robustness.
% 
% As the contracts for service interfaces are designed to ensure the expected
% result after the task performed by the service, and that if the contract is
% broken, the service does not apply to the application, we try to ensure
% the correctness by applying contracts in independent services.
% 
% Likewise with the robustness, after a contract is broken, the specification
% describes alternative paths for the user does not notice the error.
% 
% Thus, we can say that the use of design by contract for services in
% service-oriented applications can ensure the reliability of these
% kind of applications.

\begin{quotation}\sf\footnotesize
\noindent
2 - Senti falta de justificativas de porque a proposta foi desenvolvida apenas
para Web services. Observe que existem diversos servi\c cos que n\~ao s\~ao Web,
ou seja, n\~ao s\~ao descritos em WSDL, n\~ao s\~ao armazenados em UDDIs e usam outros
protocolos de comunica\c c\~ao diferentes de SOAP.   
\end{quotation} 

% Although not mentioned, the methodology can be applied to any service approach,
% not necessarily Web services. If observed, the $\pi$-PEWS specifications
% generated for the examples present not only WSDL. It is possible to use
% the methodology even if the used approaches are JSON,
% REST, Java RMI, WCF, and so on. As contracts are about functions, the
% restrictions described  through the contracts can used for any
% approach, not only Web services.
% 
% A more detailed discussion of this aspect will be inserted in the new version
% of the thesis' manuscript.

\begin{quotation}\sf\footnotesize
\noindent
3 - Al\'em da necessidade de remo\c c\~ao do termo ``reliable'' no t\'itulo,
sugiro que o t\'itulo da tese tamb\'em deveria considerar o fato de que
aplica\c c\~oes que tem servi\c cos como elementos de primeira classe s\~ao
referidas na literatura como ``service-oriented applications'' e n\~ao
``service-based applications''. N\~ao sei se houve uma discuss\~ao sobre isto,
mas esta diferen\c ca \'e significativa.
\end{quotation}

% The use of the expression ``\textit{service-based}'' was used as a synonym for
% ``\textit{service-oriented}''. We understand the need to better match the title,
% for ``\textit{service-oriented}'' application. However, we consider it is
% unnecessary to remove the word \textit{reliability}, because its concept is
% based on the idea of contracts (see answer to question 1).
% 
% Thus the title will be updated to: ``\textbf{A Methodology for Building
% Reliable Service-Oriented Applications.}''

\begin{quotation}\sf\footnotesize
\noindent
4 - \'E preciso explicar no texto o que \'e uma aplica\c c\~ao orientada a
servi\c co confi\'avel, ou seja, qual a no\c c\~ao de ``confiabilidade''
adotada. Observe que ``confiabilidade'' tamb\'em \'e um RNF. Caracterizar bem a
confiabilidade destas aplica\c c\~oes ajudaria a entender como a metodologia
trata as particularidades deste requisito n\~ao funcional. Neste ponto, vale a
pergunta: e se as aplica\c c\~oes precisassem ser ``seguras'' (outro requisito
n\~ao funcional), a metodologia poderia ser tamb\'em aplicada?      
\end{quotation}

%See answer to question 1. 
 
\begin{quotation}\sf\footnotesize
\noindent
5 - Deveria haver uma discuss\~ao na tese sobre a consist\^encia dos modelos.     
\end{quotation}

% *We will provide a discussion about consistency of models in the final version
% of the thesis manuscript.

\begin{quotation}\sf\footnotesize
\noindent
6 - Por que n\~ao foi feita nenhuma valida\c c\~ao ``quantitativa'' para mostrar quanto
a metodologia proposta ``facilita o desenvolvimento de aplica\c c\~oes
orientadas a servi\c co'' (ver defini\c c\~ao de valida\c c\~ao na pp. 116)? N\~ao h\'a evid\^encias de que a
metodologia facilita o desenvolvimento de aplica\c c\~oes orientadas a servi\c co.
\end{quotation}

% We will make an evaluation of the characteristics of the generated
% specification. As our final result is a specification of service composition in
% PEWS, we will evaluate quantitative data generated (in terms of lines of
% specification).
% 
% We will evaluate with works that generate specifications for service
% composition, such as the approach proposed by Nikola Milanovic
% \cite{Milanovic2006} which generates specifications in B.

\begin{quotation}\sf\footnotesize
\noindent
7 - N\~ao h\'a uma discuss\~ao de porque tratar RNF \'e dif\'icil ou porque SOC
facilita o tratamento destes requisitos.
\end{quotation}
 

 
\begin{quotation}\sf\footnotesize
\noindent
8 - Por que Web services e n\~ao Servi\c cos foram considerados? Por que o trabalho
considera apenas Web services? Existe uma raz\~ao particular para isto, uma vez
que torna a solu\c c\~ao restrita ao universo de Web Services?  
\end{quotation}

%See answer to question 2.

\begin{quotation}\sf\footnotesize
\noindent
9 - Verificar a frase ``\ldots some proposals extend WSDL adding behavioral
characteristics, such as PEWS[27], BPEL4WS\ldots'' Observe que BPEL4WS n\~ao \'e uma
extens\~ao de WSDL. WSDL \'e uma nota\c c\~ao para defini\c c\~ao de interface de servi\c cos e
WS-BPEL \'e uma notao para composi\c cao de servi\c cos, ou seja, s\~ao nota\c c\~oes
com prop\'ositos muito distintos. Considere reescrever esta frase.    
\end{quotation}

% ``\textit{\ldots some proposals specify services and its compositions by adding
% behavioral characteristics, such as PEWS[27], BPEL4WS\ldots}''

 
\begin{quotation}\sf\footnotesize
\noindent
10 - Na frase a seguir n\~ao fica claro como MDA alinha os conceitos de RNFs e
SOC: ``MDA [67] is an important approach for the alignment between highlevel
information modelling, non-functional requirements\ldots''. Na pr\'atica, \'e
preciso explicar porque o uso de MDA favorece/ajuda o tratamento de RNFs.
\end{quotation}

 

\begin{quotation}\sf\footnotesize
\noindent
11 - Observe na frase a seguir que WSDL e WS-BPEL n\~ao s\~ao ``plataformas de
servi\c co'': ``MDA allows the specification of a system as an abstract model,
which may be realized as a concrete implementation (program) for a particular service
platform (e.g. WSDL, BPEL or PEWS).''    
\end{quotation}

% ``MDA allows the specification of a system as an abstract model,
% which may be realized as a concrete implementation (program) for a particular service
% description or specification language (e.g. WSDL, BPEL or PEWS).''

\begin{quotation}\sf\footnotesize
\noindent
12 - Rever ou explicar a frase a seguir: ``The design addresses the functional
requirements while architecture provides the non-functional requirements like
scalability, reliability and performance are realized.'' Esta frase sugere que o
projeto (design) trata os requsitos funcionais enquanto a arquitetura trata os
RNFs. Na pr\'atica, no entanto uma diferen\c ca b\'asica destes requisitos n\~ao \'e a etapa de desenvolvimento em que eles s\~ao tratados, mas o fato de que normalmente
os requisitos funcionais est\~ao confinados (ou s\~ao implementados) em elementos
pontuais da implementa\c c\~ao. Por sua vez, os RNFs s\~ao pervasivos, ou seja, est\~ao
normalmente espalhados em toda a implementa\c c\~ao. Por exemplo, para ser seguro,
todas as partes do sistema precisam ser seguras.       
\end{quotation}



\begin{quotation}\sf\footnotesize 
\noindent
13 - Sugiro que tamb\'em seja discutido na tese o seguinte ponto: associar RNFs a
``composi\c c\~oes de servi\c cos'' ou a ``servi\c cos'' pode ser muito
dif\'icil, pois alguns RNFs s\~ao ``distributivos''. Imagine que o
desenvolvedor define que a composi\c c\~ao (e.g., formada por 5 servi\c cos) \'e segura. Isto implica (mesmo que n\~ao seja dito
pelo desenvolvedor) que todos os servi\c cos precisam ser seguros e que todas as
comunica\c c\~oes entre ele s\~ao seguras. Mas, imagine que um dos servi\c cos
n\~ao \'e seguro. Como esta situa\c c\~ao \'e tratada pela metodologia? Quais os artefatos
gerados no final?      
\end{quotation}



\begin{quotation}\sf\footnotesize
\noindent
14 - Senti falta de cita\c c\~oes a trabalhos de John Mylopoulos, cujo livro e
artigos s\~ao os mais importantes na \'area de RNFs. Em particular, o livro
``Non-Functional Requirements in Software Engineering'' \'e uma esp\'ecie de
``bíblia'' da \'area. Al\'em desta, existe uma vasta literatura sobre RNFs n\~ao
mencionada no texto: KAOS, i-star, NFR, URN/GRL (padr\~ao da ITU-T). A quase totalidade dos
elementos presentes nos metamodelos propostos j\'a constam nos trabalhos
mencionados acima, e.g., NF-Attribute, NF-Requirement, NF-Action, NF-Properties.
Inclusive, j\'a existem tamb\'em metamodelos e UML profiles para modelagem de RNFs. 


Por fim, tamb\'em senti falta de men\c c\~ao aos padr\~oes WS-* que se
relacionam a RNFs: WS-Policy, WS-SecurityPolicy, WS-Reliability, WS-Transaction,
e ``Quality Model for Web Services''.
\end{quotation}

 

\begin{quotation}\sf\footnotesize
\noindent
15 - Acredito que as Research Questions poderiam ser melhor formuladas. Por
exemplo, em rela\c c\~ao RQ1 (``How are NFRs modelled by existing methodologies for
developing reliable Web services''), as nota\c c\~oes para expressar RNFs quase
nunca est\~ao associadas a metodologias de desenvolvimento de software (muito menos a
metodologias -ainda muito escassas - de desenvolvimento orientado a servi\c
co). A maioria das nota\c c\~oes para expressar RNFs s\~ao definidas
isoladamente, pois o tratamento explícito de RNFs ainda \'e muito raro. Acredito que por conta disto
voc\^e n\~ao encontrou i-star, GRL, NFR e KAOS, pois exceto NFR, os outros n\~ao
est\~ao integrados a nenhuma metodologia de desenvolvimento de software.         
\end{quotation}


 
\begin{quotation}\sf\footnotesize
\noindent
16 - N\~ao entendi a RQ4 e nem as poss\'iveis respostas a RQ6  
\end{quotation}


 
\begin{quotation}\sf\footnotesize
\noindent
17 - Observando os strings utilizados para a busca nas bases bibliogr\'aficas, \'e
poss\'ivel observar que: no mundo de servi\c cos, o termo QoS \'e muito mais
comum do que ``non-functional requirements'' e s\~ao usados como sin\^onimos na \'area. Isto
pode ter tido um impacto muito grande nos resultados retornados.   
\end{quotation}



\begin{quotation}\sf\footnotesize
\noindent
18 - Senti falta tamb\'em de uma discuss\~ao sobre ``correla\c c\~ao'', ``conflitos'' e
``prioridade'' entre RNFs. Estes dois aspectos s\~ao muito discutidos quando
fala-se em RNFs.   
\end{quotation}



\begin{quotation}\sf\footnotesize
\noindent
19 - Observe que o trabalho de D'Ambrogio [34] tamb\'em tem MDA, RNFs e servi\c cos,
ou seja, ele deveria estar na mesma \'area que a proposta da tese na Figura 3. 
\end{quotation}




\begin{quotation}\sf\footnotesize
\noindent
20 - Esclarecer o que s\~ao Business Services. Este termo n\~ao \'e comum na \'area de servi\c cos. 
\end{quotation}

  

\begin{quotation}\sf\footnotesize
\noindent
21 - Uma das RQs poderia ser ``metodologias fazem o desenvolvimento de
composi\c c\~oes por orquestra\c c\~ao ou por coreografia?'' Isto mereceria tamb\'em uma
discuss\~ao na tese, pois s\~ao as estrat\'egias normalmente usadas na computa\c c\~ao
orientada a servi\c cos. Ainda relacionado a isto, outro ponto que deveria ter sido
discutido na tese \'e o fato de que metodologias para este tipo de desenvolvimento
tem como etapas principais a ``sele\c c\~ao'' e a ``combina\c c\~ao'' de servi\c cos. Compare
estas etapas com as etapas tradicionais.       
\end{quotation}

  

\begin{quotation}\sf\footnotesize
\noindent
22 - N\~ao tenho certeza, mas acredito que alguns elementos dos metamodelos da
$\pi$SOD-M j\'a tenham sido definidos na SOD-M. Seria interessante, se isto est\'a
acontecendo, destacar estes elementos para deixar claro ao leitor os elementos
que s\~ao exclusivos da $\pi$SOD-M.    
\end{quotation}
 
% The concepts added by our approach as form to extend SOD-M proposal is
% highlighted in our meta-models by dotted lines around the entities. The new
% concepts are:
% 
% . \textit{$\pi$-UseCase} model: Constraint, Constraint Type, Non-Functional
% Requirement, and Non-Functional Attribute.
% 
% . \textit{$\pi$-ServiceProcess} model: Contract, Assertion, Assertion Property,
% Exceptional Behaviour.
% 
% . \textit{$\pi$-ServiceComposition} model: Policy, Rule, Event Type, Variable,  Non-Functional
% Requirement. 
% 
% . \textit{$\pi$-PEWS} model: There was no definition of the $\pi$-PEWS concepts
% in the original SOD-M. Thus, all elements are new. 
% 
% The main purpose of adding these elements is the need to better represent the
% constraints associated with the services and how these restrictions can be
% represented by each meta-model entity. As the restrictions associated with the
% services are refined at each iteration, the representation also changes in each
% meta-model.    

\begin{quotation}\sf\footnotesize
\noindent
23 - Observando a Figura 4, \'e poss\'ivel observar que $\pi$SOD-M tem as mesmas
etapas de SOD-M, mas com foco no RNFs. Isto sugere (posso estar enganado) que toda a
parte ``funcional'' foi aproveitada na SOD-M. Isto \'e verdade?   
\end{quotation}

% Yes, this is true.  

\begin{quotation}\sf\footnotesize
\noindent
24 - DEVISE \'e uma metodologia?  
\end{quotation}



\begin{quotation}\sf\footnotesize
\noindent
25 - N\~ao \'e muito claro como um ``requisito n\~ao-funcional'' pode ser representado
por um ``use case''.
\end{quotation}

  

\begin{quotation}\sf\footnotesize
\noindent
26 - Talvez esteja claro no texto, mas n\~ao ficou claro para mim os mapeamentos
``Constraint'' -> Contract e Contract-> Policy s\~ao realizados.
\end{quotation}



\begin{quotation}\sf\footnotesize
\noindent
27 - Senti falta de uma descri\c c\~ao precisa do que sejam NF-Attributes,
NF-Properties e NF-Requirements. 
\end{quotation}



\begin{quotation}\sf\footnotesize
\noindent
28 - N\~ao entendi a frase ``The quality properties at the system level represent
a behaviour that is part of the workflow.''
\end{quotation}



\begin{quotation}\sf\footnotesize
\noindent
29 - Observar esta parte ``$\pi$SOD-M is a MDA (Model Driven Architecture) based
methodology. It provides a framework for building service compositions
considering their non-functional requirements.'' A metodologia fornece um
framework? Os conceitos de metodologia e framework s\~ao muito distintos.   
\end{quotation}



\begin{quotation}\sf\footnotesize
\noindent
30 - N\~ao est\'a muito clara (justificada) a necessidade de um ``Process Model'' e
um ``Composition Model''. Observe que em nota\c c\~oes como WS-BPEL os elementos destes
dois modelos est\~ao de certa forma juntos, ou seja, talvez seja interessante
justificar porque a metodologia adota esta separa\c c\~ao.    
\end{quotation}



\begin{quotation}\sf\footnotesize
\noindent
31 - Senti falta de uma descri\c c\~ao passo-a-passo da Figura 5, por exemplo,
``Inicialmente tem-se uma especifica\c c\~ao de um processo de neg\'ocio que \'e
transformado em um UseCase model...'' Esta explica\c c\~ao at\'e existe, mas est\'a
dilu\'ida nas p\'aginas subsequentes do texto quando voc\^e diz ``After modelling the
system services and feature...'' (pp. 62). Como esta figura \'e muito importante,
ela deveria ser bem descrita.      
\end{quotation}



\begin{quotation}\sf\footnotesize
\noindent
32 - N\~ao h\'a uma explica\c c\~ao sobre (i) porque a metodologia foi estruturada em
tr\^es vis\~oes (Business, System and Policy) e (ii) como chegou-se a estas tr\^es
vis\~oes.  
\end{quotation} 

% The Business and Services views were inherited from SOD-M \cite{CastroMV11}, the
% Policy view encompass the elements and concepts necessary to describe constraints for
% services. Thus, it was included in the structure of SOD-M the Policy view
% as a way to represent these concepts during the application design.   

\begin{quotation}\sf\footnotesize
\noindent
33 - Sugiro uma explica\c c\~ao sobre o mapeamento apresentado na Figura 16. Por
exemplo, \'e preciso justificar porque uma ``Business Service'' \'e representado em
UML por um ester\'otipo.  
\end{quotation}


\begin{quotation}\sf\footnotesize
\noindent
34 - Observe que processos em WS-BPEL possuem muito mais do que ``sequence of
activities'' (ver frase ``It can be visualized with a flowchart as a sequence of
activities with interleaving decision points''). Na pr\'atica, por tr\'as desta
minha observa\c c\~ao est\'a a constata\c c\~ao de que o modelo para defini\c c\~ao de processos proposto ( PI-ServiceProcess) \'e muito mais simples do aqueles apresentados em
nota\c c\~oes como URN e WS-BPEL (usadas com o mesmo objetivo e que j\'a possui
metamodelos).    
\end{quotation}


\begin{quotation}\sf\footnotesize
\noindent
35 - Quem \'e o ``Application designer''? Qual o perfil? \'e algu\'em de neg\'ocio ou de
TI? Isto \'e importante estar definido na metodologia, pois provavelmente existem
v\'arios atores (business expert, qos expert, TI expert) envolvidos nas v\'arias
etapas da metodologia. Por exemplo, algu\'em de neg\'ocio seria capaz de definir uma
express\~ao como estas apresentadas na Figura 20 (e.g., $\#$bankBlance $>$
paymentValue \&\& \ldots ). Veja ainda na p\'agina 85: quem \'e o
``designer'' referido na frase ``The designer must specify\ldots''.      
\end{quotation}


\begin{quotation}\sf\footnotesize
\noindent
36 - Que linguagens s\~ao estas ``behavioural web service interface languages''?    
\end{quotation}


\begin{quotation}\sf\footnotesize
\noindent
37 - Seria interessante justificar porque a linguagem PEWS foi escolhida para a
implementa\c c\~ao. Isto remete a outro importante, a metodologia \'e desacoplada desta
linguagem, ou seja, ela suportaria a gera\c c\~ao de composi\c c\~oes execut\'aveis em
WS-BPEL?   
\end{quotation}



\begin{quotation}\sf\footnotesize
\noindent
38 - Por que as pol\'iticas n\~ao s\~ao descritas em WS-Policy? Existe tamb\'em
metamodelo deste padr\~ao? WS-Policy \'e amplamente conhecido e j\'a suportado por
diversos ambientes de execu\c c\~ao para aplica\c c\~oes orientadas a servi\c cos.   
\end{quotation}

% Resposta

\begin{quotation}\sf\footnotesize
\noindent
39 - J\'a existia um metamodelo de PEWS?   
\end{quotation}

% No. The PEWS meta-model was specified based on its language and its extension (during the PhD
% stage in Grenoble), where we added the concepts of contracts.

\begin{quotation}\sf\footnotesize
\noindent
40 - Por que as regras de transforma\c c\~ao n\~ao foram descritas em ATL? 
\end{quotation}

% All transformations were also described in ATL, but were not included in the
% thesis' manuscript. We will insert as an appendix of the
% thesis, or as a link address where anyone can download (with the specific
% referenc in the text of the thesis).
   
\begin{quotation}\sf\footnotesize
\noindent
41 - Senti falta dos requisitos do ambiente de desenvolvimento proposto. Veja
que a Figura 41 j\'a mostra a arquitetura. Quais os requisitos que geraram esta arquitetura?
\end{quotation}
 
% The environmental requirements are the Eclipse Modelling (Galilleo or higher)
% and all plugins proposed, \textit{$\pi$-UseCase, $\pi$-ServiceProcess,
% $\pi$-SerciveComposition} and \textit{$\pi$-PEWS} editors; and also the
% transformation plugins. Because the environment is proposed in the
% context of Eclipse, the environmental requirements are also the same needed to
% utilize the Eclipse tool.
 
\begin{quotation}\sf\footnotesize  
\noindent
42 - O ambiente n\~ao deveria ser estruturado em ``vis\~oes'' como a metodologia?
\end{quotation}


\begin{quotation}\sf\footnotesize
\noindent
43 - Ao inv\'es de ``estudos de caso'' colocaria ``Examples''. Removeria o Estudo
de Caso 1, pois ele foi usado em toda a tese e todos os principais elementos j\'a
foram apresentados no Cap\'itulo 3 (inclusive as figuras s\~ao as mesmas). 
\end{quotation}

% As suggested, we will use the term ``\textbf{\textit{Examples}}'' to the case
% studies presented. Likewise, instead of ``\textit{Validation}'', we use
% the term ``\textbf{\textit{Evaluation}}'', in Chapter 5, as a way to better represent
% what was done.

\begin{quotation}\sf\footnotesize
\noindent
44 - N\~ao fica claro o que \'e a ``an\'alise qualitativa'' mencionada.
\end{quotation}

% Resposta

\begin{quotation}\sf\footnotesize
\noindent
45 - Explicar melhor os trabalhos futuros. Evite itemiz\'a-los.
\end{quotation}

% The items will be described more detailed in order to make clear what will be
% done in \textit{Future Work}.

\section{Respostas aos questionamentos e sugest\~oes do Prof. Nelson Souto Rosa}
\label{sec:respostas}
 
De acordos com os questionamentos apresentados e listados acima, este documento
tem por objetivo apresentar e detalhar os conceitos,
defini\c c\~oes e pontos principais que n\~ao ficaram claros na descri\c c\~ao do texto da
tese que foi enviado aos membros da banca.

Os aspectos que ser\~ao discutinos neste documento de resposta visa proporcionar
uma defini\c c\~ao mais coerente e satisfat\'oria no que diz respeito aos conceitos relacionados a:
(i) Requisitos n\~ao-funcionais, (ii) Aplica\c c\~oes orientadas a servi\c co, (iii)
desenvolvimento dirigido a modelos e tamb\'em (iv) como os apresentamos no
contexto da metodologia proposta, $\pi$SOD-M. \'E importante destacar que estas
sugest\~oes e as respostas aos questionamentos ser\~ao considerados para a vers\~ao final do documento da tese, como forma de
melhorar e deixar mais claro ao leitor os benef\'icios de se utilizar a
metodologia $\pi$SOD-M, bem como os conceitos/defini\c c\~oes nela
apresentados.
 
Sempre que for apresentado a nota\c c\~ao $R_n$ no decorrer
do texto, esta faz refer\^encia a qual d\'uvida/questionamento estamos tentando
responder. Dessa forma, caso exista a referência $R_3$, estamos fazendo a
referência a responta ao terceiro questionamento listado acima, da mesma forma
que $R_{45}$ \'e a resposta ao \'ultimo questionamento apresentado acima.
 
\bigskip
\bigskip

 
A metodologia $\pi$SOD-M foi concebida com o intuito de agregar valor a
metodologia SOD-M \cite{CastroMV11}, e também minimizar o problema de modelagem de
requisitos não funcionais para aplicações orientadas a serviços. A principal contribuição deste
trabalho é fornecer uma estrutura na qual seja possível descrever/espeficicar
restrições sobre serviços desde a concepção inicial (nível mais abstrato) do
desenvolvimento de sistemas. Nossa proposta visa refinar as restrições
(em termos de ``\textit{constraints}'' $>>$ ``\textit{contracts}'' $>>$
``\textit{policies}'') a cada iteração do desenvolvimento. Entendemos que vários
trabalhos existentes na literatura abordam a especificação e modelagem de
propriedades não funcionais em diversos aspectos. Estas abordagens detalham o
projeto de requisitos específicos como performance, segurança, usabilidade, confiabilidade,
dentre outros. No entanto, aspectos importantes do desenvolvimento não são
considerados e isso dificulta, especifalmente, o desenvolvimento de aplicações
orientadas a serviços.

Bertrand Meyer \cite{Meyer92,MeyerN93,Meyer97} argumenta que ``confiabilidade é
importante no desenvolvimento de aplicações. Meyer argumenta que reduzir erros
através da construção de componentes de software através de contratos proporciona uma maior
confiabilidade a aplicação que está sendo desenvolvida.

Com base neste conceito \cite{Meyer92,MeyerN93,Meyer97}, um componente de
software, seja um serviço ou não, que é projetado com base em contratos pode reduzir a quantidade de erros,
tornando-se mais confiável. No caso específico de serviços, que são
componentes de baixo acoplamento, a especificação e verificação
desses contratos pode ser realizada pelo ``orquestrador'' dos serviços, que deve
verificar a validade e execução desses contratos.

O conceito de confiabilidade utilizada na tese é a definição apresentada
por Bertrand Meyer \cite{Meyer92,MeyerN93,Meyer97} em sua definição de
\textbf{Design by Contract}. Para Meyer, confiabilidade engloba corretude e
robustez.

Corretude é a capacidade dos produtos de software executarem suas
tarefas como definidos por sua especificação; enquanto Robustez é a capacidade
de sistemas de software reagir adequadamente a condições anormais.

Como os contratos para interfaces de serviço são projetados com o objetivo de
assegurarem, o resultado esperado depois da execução do serviço está
relacionado com a não quebra do contrato. Se o contrato é quebrado, o
serviço não se aplica a necessidade da aplicação. Com isso, tentamos garantir a corretude através da aplicação de
contratos em serviços. Da mesma forma ocorre com o conceito de robustez,
depois que um contrato é quebrado, a especificação do contrato define caminhos
alternativos/excepcionais para o usuário não perceber o erro ($R_1$ e $R_4$).

Assim, podemos afirmar que o uso de \textit{Design by Contract} em aplicações
orientadas a serviços pode garantir a confiabilidade ao software gerado.

\bigskip
\bigskip


Embora não mencionado, a metodologia pode ser aplicada a qualquer abordagem de
serviço, não necessariamente Serviços web. Se observado, as especificações
$\pi$-PEWS geradas para os exemplos no capítulo de validação apresentam não
apenas WSDL. É possível utilizar a metodologia mesmo se as abordagens utilizadas
na construção (reuso) dos serviços são JSON, REST, Java RMI, WCF, e assim por
diante. Como os contratos são sobre funções, as restrições descritas através dos
contratos podem ser aplicada para qualquer abordagem, não apenas para os
Serviços web. 

Está implícito no manuscrito da tese que usamos apenas Serviços web. Isso
acontece pelo fato de trabalharmos apenas no nível de especificação, e neste
nível não há uma preocupação com qual abordagem irá implementar a especificação. 
No entanto, uma discussão mais detalhada sobre esse aspecto será inserida na
nova versão do manuscrito da tese ($R_2$ e $R_8$). 



\bigskip
\bigskip


 
O t\'itulo da tese foi modificado de ``\textit{A
Methodology for Building Reliable Service-Based Applications}'' para `\textit{A
Methodology for Building Service-Oriented Application in the Presence of
Non-Functional Properties}'' como forma de deixar o t\'itulo mais expressivo e
correto em rela\c c\~ao as \'areas chaves do trabalho. Entendemos que a literatura
utiliza a express\~ao \textit{Service-Oriented}, em detrimento ao adotado
anteriormento \textit{Service-Based}. Apesar desta \'ultima express\~ao ter sido
utilizada como sin\^onimo da primeira, \'e importante a adequa\c c\~ao com a \'area. Da
mesma maneira, retiramos o termo ``\textit{reliable}'' para que este n\~ao seja
entendido de maneira espec\'ifica como a \'unica propriedade a ser considerada no
trabalho, em detrimento das demais. Para isso adotamos a express\~ao
``\textit{Non-Functional Properties}'' ($R_3$).

\bigskip
\bigskip


Enquanto MDA utiliza uma linguagem de modelagem orientada a objetos
precisa (ou seja, UML) como tecnologia núcleo, ele não insiste na
importância de transformações do modelo precisos e automatizado para a concepção e implementação de
mapeamentos de PIMs para PSMs, ou de PSMs para código. MDA não oferece
mecanismos para se verificar a de consistência dos modelos desenvolvidos. No
entanto, existem alguns trabalhos que tem como foco principal verificar a
consitência destes modelos usando alguma agordagem formal
\cite{Varro04,PaigeV12}. 

A verificação de consistência ``sintática'' dos modelos é realizada por
ferramentas de definição e transformação de modelos MDA, como por exemplo o
\textit{Eclipse Modelling}. Como não era o foco inicial do nosso trabalho a
verificação semântica dos modelos e do código gerado por eles (com o objetivo de analisar a sua consistência), não
apresentamos no texto da tese uma discussão sobre este assunto. No entanto,
identificamos como trabalho futuro (pg. 146) a intenção de formalizar as regras
de transformação dos modelos ($R_5$).

\bigskip
\bigskip

Na versão final do manuscrito da tese, será realiza uma análise do código
gerado em $\pi$-PEWS. Como a metodologia gera a especificação da aplicação no
que diz respeito a serviços, workflow e contratos, iremos fazer uma comparação com
abordagem semelhantes \cite{Milanovic2006} que consideram algum tipo de
linguagem de especificação, como o método B ($R_6$). 


\bigskip
\bigskip


 Garantir propriedades não funcionais é um desafio do desenvolvimento de
 aplicações em geral, em especial aplicações distribuidas que dependem de
 recursos de rede para que os serviços sejam executados.
 No entanto, como serviços são componentes independentes e tem uma granularidade
 mais fina, garantir que restrições sejam satisfeitas nestes serviços é mais fácil. Como
 cada serviço disponibiliza sua interface de acesso para que as ações sejam
 chamadas, os clientes destes serviço tem a possibilidade de verificar se o
 resultado o satisfaz ou não, inclusive durante a execução da aplicação. Por
 outro lado, a garantia de prorpiedades não funcionais em composição de serviço
 não é tão trivial de resolver. Isso ocorre pelo fato dos requisitos não
 funcionais, na maioria das vezes, terem características concorrentes ou até
 opostas no que diz respeito a tais requisitos. Por exemplo, para se
 proporcionar segurança, todos os serviços da composição devem ser seguros. Para
 se garantir tempo de responta satisfatório, todos os serviços da composição
 devem fornecer os resultados obedecendo as restrições do cliente. No pior caso
 em relação a garantia de requisitos não funcionais em composição de serviços,
 se um serviço garante a segurança e outro performance, as restrições como um
 todo acabam não sendo garantidas. 
 
 Devido a estes problemas, os requisitos não funcionais são tratados em serviços
 de maneira particular, por exemplo, a maioria dos trabalhos tentam garantir
 requisitos específicos na modelagem de aplicações orientadas a serviços.
 Sabendo desse problema, tentamos fornecer com o nosso trabalho uma abordagem um
 pouco mais geral baseada em contratos para os serviços presentes na
 especificação do workflow. Os contratos em $\pi$-PEWS podem ser especificados
 tanto para serviços simples ou compostos. O tratamento que damos no caso de serviços compostos é
 que caso haja algum conflito em relação aos contratos, o contrato é quebrado e
 a composição não é satisfatória para a execução da aplicação. É importante
 destacar que como nossa abordagem é baseada em contratos para serviços, a
 garantia das propriedades não funcionais está diretamente relacionado a
 verificação dos contratos, entradas e saídas desejadas para um serviço simples
 ou composto. ($R_7$)
 
 \bigskip
\bigskip

De acordo com a frase seguinte,

``\textit{\ldots some proposals extend WSDL adding behavioral characteristics,
such as PEWS[27], BPEL4WS\ldots }''

como esta continha informação inconsistente, a atualizamos para:

``\textit{\ldots some proposals specify services and its compositions by adding
behavioral characteristics, such as PEWS[27], BPEL4WS\ldots}'' ($R_9$). 
 
 
 \bigskip
 \bigskip
 
 
 MDD é uma abordagem importante para alinhar informações na modalagem de níveis
 mais abstratos e requisitos não funcionais. Como no desenvolvimento baseado em
 modelos, as informações vão sendo refinadas a cada nível através de
 transformação de modelos, os NFRs podem ter sua definição melhor descrita.
 
Cada vez mais MDD é empregado para orientar o desenvolvimento com foco na
geração de código a partir de modelos. Diferentemente, a modelagem de aspectos e
propriedades não-funcionais continua difícil. Modelos que descrevem requisitos
não-funcionais pode ser utilizados para expressar, na fase de especificação,
características transversais da aplicação. A medida que é realisado o
desenvolvimento destes modelos, propriedades essenciais do software são
apresentadas de maneira mais concreta \cite{Rottger04}.
 
 O desafio no uso de MDD para na modelagem dos aspectos 
 transversais da aplicação desde o nível mais abstrato de design é a
 capacidade de utilizar diferentes tipos de modelos para diferentes fins e
compreender as diferenças entre as terminologias para os aspectos não
funcionais \cite{LimingZhu2009}. ($R_{10}$)
 
 \bigskip
\bigskip

Considerando que WSDL, BPEL e PEWS não são plataformas de serviços, mas
linguagens para descrição e especificação de serviços, descrevemos que:

 ``\textit{MDA allows the specification of a system as an abstract model, which may
 be realized as a concrete implementation (program) for a particular service
 description language or specification language (e.g. WSDL, BPEL or PEWS).}''
 ($R_{11}$).
 
 \bigskip
 \bigskip
 
 
 A frase: 
 
 ``The design addresses the functional
requirements while architecture provides the non-functional requirements like
scalability, reliability and performance are realized.'' 

será removida. ($R_{12}$)

\bigskip
\bigskip


O Objetivo da RQ4 foi verificar de existia algum ``padrão'' ou classificação de
NFR para metodologias de desenvolvimento. Com essa pergunta procuramos verificar
se já existiam abordagens que trabalhavam com NFRs para serviços, no contexto de
uma metodologia desenvolvimento. Dessa forma, os resultados sobre KAOS e i-star,
por exemplo, não foram retornados como resultado. ($R_{15}$).

\bigskip
\bigskip




Em relação a RQ4, nós já estamos desenvolvendo um trabalho específico de análise
mais detalhada através de uma outra revisão sistemática para requisitos não-funcionais. Uma Query
várida para um melhor resuldado poderia ser expressa através de:

\textsc{[Non-Functional requirements or Non-Functional properties or Non-Functional
attributes or QoS] And [Service oriented application development or Web
Service based applications development or Service Composition development]} 

 Sobre a RQ6, queremos saber em nossa análise se os requisitos não-funcionais
 tratados no trabalho analisado consideram serviços simples ou compostos. ($R_{16}$ e
 $R_{17}$)
 
 \bigskip
 \bigskip
 
 D'Ambrogio \cite{DAmbrogio06} propoe uma extensão WSDL para descrever QoS em
 Web Services, descrevendo uma abordagem em MDA de apenas 1 nível de transformação. A proposta
 de D'Ambrogio não está propondo uma metodologia, mas sim uma extensão de WSDL
 usando MDA. Dessa forma, entendemos que a proposta de D'Ambrogio se distingue
 um pouco da nossa abordagem. ($R_{19}$)
 
 \bigskip
 \bigskip


Serviços de negócios são serviços que fazem parte de um requisito negócio e
atende a uma necessidade de usuário. BPMN define o conceito de \textit{Service
operation} que é uma operação de um serviço que faz parte do processo de
negócio \cite{bpmn}. Na área de serviços, um business service é representado
por um serviço (ou composição) que será executado no processo de negócio.
($R_{20}$)




  \bigskip
 \bigskip
  
Uma descrição detalhada da diferença entre orquesteação e coreografia de
serviços estará presente no capítulo de Backgroud na versão final do manuscrito
da tese como sugerido. Estes conceitos serão descritos neste capítulo,
aliado a outros conceitos importante, que são: MDA, Serviços (com a
diferenciação entre orquestração e coreografia), Composição de Serviços
\cite{NguyenHPCM09} e Requisitos não funcionais
\cite{MylopoulosBook99,UszokBJ04,Chung2009,Yu97,AmyotM02}. ($R_{21}$ e $R_{14}$) 


\bigskip
\bigskip

Os conceitos inseridos pela nossa abordagem como forma de estender SOD-M foram
destacados no manuscrito da tese com linhas pontilhadas ao redor do conjunto de
entidades. Os conceitos descritos em cada meta-modelo de  $\pi$SOD-M que foram
acrescentados são:

 
. Meta-modelo \textit{$\pi$-UseCase}: Constraint, Constraint Type,
Non-Functional Requirement, and Non-Functional Attribute.

. Meta-modelo \textit{$\pi$-ServiceProcess}: Contract, Assertion,
Assertion Property, Exceptional Behaviour.

. Meta-modelo \textit{$\pi$-ServiceComposition}: Policy, Rule, Event Type,
Variable,  Non-Functional Requirement.

. Meta-modelo \textit{$\pi$-PEWS}: Não existia nenhuma definição dos
conceitos de $\pi$-PEWS em SOD-M. Todos os elementos do meta-modelo de  $\pi$-PEWS foram
definidos a partir de sua linguagem. 

$\pi$SOD-M herda toda a parte funcional de SOD-M. ($R_{22}$ e $R_{23}$)

  \bigskip
\bigskip
 
Apesar da metodologia DEVISE \cite{DEVISE} não ser uma metodologia de
desenvolvimento, ela é uma metodologia para definição de infra-estrutura de Serviços web. Por este motivo inserimos esta
referência como como trabalho relacionado no capítulo de Estado da Arte (cap.
2). ($R_{24}$)


\bigskip
\bigskip

Em $\pi$SOD-M, um \textsc{Use Case} tem um conjunto de \textsc{Constraints} (em
$\pi$-UseCase Model). As \textsc{Constraints} são agrupadas em \textsc{Contratos}, onde as
\textsc{Constraints} de um mesmo caso de uso se transformam em
\textsc{Assertions}, e essas \textsc{Assertions} compoem um contrato (em
$\pi$-ServiceProcess Model). Por fim, \textsc{Contratos} com propriedades
não-funcionais comuns (por exemplo, segurança), são agrupados em uma
\textsc{Policy} (em $\pi$-ServiceComposition Model). ($R_{26}$)


\bigskip
\bigskip



A frase \ldots

``\textit{The quality properties at the system level represent
a behaviour that is part of the workflow.}''

quer dizer que as propriedades não funcionais do workflow (*que são
descritas como \textit{assertions}, definidas através de pré ou pós-condições*),
representam o comportamento desejado de cada parte (ação/serviço) do workflow. Esse conceito
está baseado na definição de Design by Contract \cite{Meyer97}. 

No entanto, entendemos que a frase não está totalmente clara e iremos modificar
para:

``\textit{The quality properties at the system level, which are defined as assertions
(pre- and post-conditions), represent the behaviour aspects required of the
actions that is part of the main workflow.}'' ($R_{28}$) 



\bigskip
\bigskip 

 
Na frase:

``\textit{$\pi$SOD-M is a MDA (Model Driven Architecture) based
methodology. It provides a framework for building service compositions
considering their non-functional requirements.}''

framework significa uma estrutura que engloba conceitos básicos para resolver
algum problemas. Neste caso específico a metodologia provê um conjunto de
conceitos, passos e transformações para se desenvolver aplicações orientadas a
serviços, na presenta de requisitos não-funcionais. ($R_{29}$)

\bigskip
\bigskip
 
A figura 5 será descrita mais detalhadamente na versão final do manuscrito da
tese.

Esta figura descreve o passo a passo do desenvolvimento baseado em $\pi$SOD-M.
A partir dos documentos de especificação de negócio e especificação de
requisitos \cite{scube2010book}, o modelo de $\pi$-UseCase é desenvolvido. A
partir deste modelo é realizada uma sequência de transformações com o objetivo
de melhor refinar os conceitos necessários para o desenvolvimento.
A partir do modelo de $\pi$-UseCase, o qual representa os casos de uso,
requisitos e restrições da aplicação, o modelo de $\pi$-ServiceProcess é gerado. 

O modelo de $\pi$-ServiceProcess descreve o processo de negócio a ser executado,
e suas respectivas restrições. A partir deste modelo, o modelo de 
$\pi$-ServiceComposition é gerado. Este modelo é semelhante ao anterior, no
entanto descreve quais serviços externos se relacionam com cada ação/operação no
processo de negócio. 
 
A partir do modelo de  $\pi$-ServiceComposition é possível gerar uma
especificação para qualquer linguage que descreva composição de serviços. No
caso específico do nosso trabalho, foi gerado código $\pi$-PEWS. No entanto,
é possível que seja gerado código para qualquer linguage, mas é necessário a
descrição do meta-modelo da linguagem e as regras de transformação.

 O objetivo principal de se ter dois modelos para descrever o processo de
 execução de serviço $\pi$-ServiceProcess e $\pi$-ServiceComposition é fazer com
 que haja uma separação clara das necessidades de negócio, e quais serviços
 iram implementar estas necessidades. Apesar de WS-BPEL já definir conceitos
 semelhantes, o nosso objetivo foi também simplificar a descrição destes
 processo. ($R_{30}$, $R_{31}$ e $R_{34}$)

\bigskip
\bigskip
 

As visões de Negócios e Serviços (Business e Service) foram herdadas de
SOD-M \cite{CastroMV11}, a visão de Política (Policy) visa abranger os elementos
e conceitos necessários para descrever restrições de serviços. Assim, foi
incluído na estrutura original de SOD-M esta nova visão como uma
forma de representar os aspectos não-funcionais durante o projeto da aplicação.
($R_{32}$)



\bigskip
\bigskip

A figura 16 descreve como representamos os elementos de um modelo de
$\pi$-UseCase através de UML. Um Business Service não é representado através de
um esteriótipo. O único elemento que é representado através de esteriótipo neste
modelo é uma \textit{Constraint}. Um \textit{Business Service} é identificado
apenas como um comentário. Este comentário está ligado a um caso de uso. Isso
significa que este caso de uso será uma ação da aplicação que fará parte de
um serviço de negócio. Um serviço de negócio será uma ação/serviço simples da
aplicação que está sendo desenvolvida, ou um serviço composto. Nesse caso a
figura 16, semelhante as figuras 17 e 18 não mostra um mapeamento, mas como os
conceitos do meta-modelo podem ser representados através de UML. ($R_{33}$)

\bigskip
\bigskip

A linguagem $\pi$-PEWS foi escolhida para implementação pelo fato de já estar
trabalhando com essa linguagem durante toda a tese, e pelo fato também desta
linguagem ter sido desenvolvdida pelo nosso grupo de pesquisa. Desenvolvemos o
metamodelo de PEWS e fizemos o mapeamento do n\'ivel PIM para PSM ($R_{39}$).
Como a metodologia proposta é realmente desacoplada de qualquer linguagem, é
possível gerar código para WS-BPEL, XAML e outras linguagem de composição de
serviços, basta apenas a descrição do meta-modelo e o as regras de mapeamento
(transformações entre os modelos). ($R_{37}$)

\bigskip
\bigskip

Todas as transformações foram descritas em linguagem natural, visual e em
ATL, no entanto as transformações em ATL mas não foram incluídas na manuscrito
tese pelo fato de já terem sido descritas em linguagem natural. Como existe mais
de uma linguagem para transformação, como o QVT e ATL, preferimos omitir estas
transformação para o leitor da tese. Os exemplos das transformação
em ATL apresentados no capítulo de embiente da metodologia são apenas para
apresentar a estrutura geral de ATL e as principais transformações. 

No entanto, como forma de agregar valor ao texto da tese, iremos acrescentar em
forma de apêndice da tese, as transformações descritas em ATL. ($R_{40}$)


\bigskip
\bigskip
 
Os requisitos de ambiente são: a ferramenta Eclipse Modelling (versão Galilleo
ou superior) e todos os plugins proposto pela motodologia, os editores \textit{$\pi$-UseCase, $\pi$-ServiceProcess,
$\pi$-SerciveComposition} e \textit{$\pi$-PEWS}, além dos
plugins de transformação. Uma vez que o ambiente é proposto no
contexto da ferramenta Eclipse, os requisitos de ambiente necessários
são os mesmos requisitados pela ferramenta Eclipse. ($R_{41}$)

\bigskip
\bigskip

As visões propostas da metodologia separam os conceitos de serviço, negócio e
políticas, como forma de classificar estes elementos/conceitos. Esta separação
não implica em um efeito direto da modelagem ou transformação. Como o
desenvolvimento usando $\pi$SOD-M integra os elementos de cada visão em todas as
iterações e transformações, não vimos a necessidade de dividir o ambiente em
visões, pelo fato das visões propostas serem uma forma de classificar conceitos
importante para cada fase e transformação. ($R_{42}$)

\bigskip
\bigskip


Como sugerido, vamos usar o termo ``\textbf{\textit{Exemplos}}'' para os estudos
de caso apresentados. Do mesmo modo, em vez de ``\ textit{Validação}'', usaremos
o termo `` \textbf{\textit{Avaliação}}'' , no capítulo 5, como uma forma de
melhor representar o que foi feito. ($R_{43}$)

\bigskip
\bigskip


No que diz respeito aos trabalhos futuros, estes foram organizados em três
grandes áreas: Validação, Desenvolvimento e Atividades de Pesquisa.

No que diz respeito a validação, é nosso objetivo fazer uma análise mais
quantitativa da metodologia. Esta análise irá verificar a quantidade de código
gerado, e como esse código pode reduzir o tempo ou custo de desenvolvimento.
Compararemos nosso método com abordagens de desenvolvimento de aplicação
orientadas a serviços que gerem uma especificação da aplicação. Nosos objetivo é
comparar o tipo de especificação gerada, e o que temos de diferente que
justifique o uso da nossa metodologia. Os resultados serão submetidos para
publicação de um journal internacional, mostrando as vantagens de se utilizar
$\pi$SOD-M.

É nosso interesse também analisar e descrever possíveis linhas de produto de
software para aplicações que sejam baseadas em requisitos não-funcionais, e como
estas linhas de produto podem ser geradas a partir da nossa metodologia
proposta. Uma outra área interessante no contexto de linhas de produto, é
verificar a variabilidade dos requisitos não-funcionais propostos pela
metodologia para aplicações orientadas a serviços.

Em relação ao desenvolvimento, seria interessante ter um ambiente completamente
integrado com a linguagem $\pi$-PEWS e seu ambiente de execução. Dessa forma
seria possível verificar se o código da especificação gerada tem alguma
inconsistência, e verificar a sua corretude em runtime. Uma outra tarefa
importante a ser relaizada em trabalhos futuros é o desenvolvimento de um
ambiente completamente visual para a modelagem da aplicação, em todos os níveis
propostos por $\pi$SOD-M.

Em relações a atividades de pesquisa, é importante que se formalise os modelos e
suas regras de transformação de forma que possamos garantir formalmente a
consistência dos modelos propostos e de suas regras de transformação. Um outro
ponto importante é a definição de metamodelos de linguagens de composição de
serviços e o mapeamento do nível PIM de $\pi$-ServiceComposition para a nova
linguagem. ($R_{45}$)

\bigskip
 



\bibliography{respostas}
\bibliographystyle{plain}

\end{document}
